home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940182.txt < prev    next >
Text File  |  1994-11-13  |  23KB  |  534 lines

  1. Date: Mon,  6 Jun 94 04:30:19 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #182
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Mon,  6 Jun 94       Volume 94 : Issue  182
  11.  
  12. Today's Topics:
  13.              An open note to Gary Coffman, KE4ZV (6 msgs)
  14.                      Ethernet address Directory?
  15.                          GRINOS AND ETHERNET
  16.                  Internet <-> Packet gateway (2 msgs)
  17.                Motorola GPS engine purchase information
  18.                 NPFPMS update version 2.20A available
  19.                           Vester SSTV board
  20.  
  21. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  22. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  23. Problems you can't solve otherwise to brian@ucsd.edu.
  24.  
  25. Archives of past issues of the Ham-Digital Digest are available 
  26. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  27.  
  28. We trust that readers are intelligent enough to realize that all text
  29. herein consists of personal comments and does not represent the official
  30. policies or positions of any party.  Your mileage may vary.  So there.
  31. ----------------------------------------------------------------------
  32.  
  33. Date: 5 Jun 1994 20:31:14 GMT
  34. From: ihnp4.ucsd.edu!swrinde!howland.reston.ans.net!wupost!crcnis1.unl.edu!ace.mid.net!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!icaen!drenze@network.ucsd.
  35. Subject: An open note to Gary Coffman, KE4ZV
  36. To: ham-digital@ucsd.edu
  37.  
  38. davidj@rahul.net (David Josephson) writes:
  39.  
  40. >Gary's letter isn't here, but Doug's open letter is a fine start. And
  41. >we have all read replies about one technical angle or another being the
  42. >seed of our discontent. But have we ever thought about applications for
  43. >packet radio? Excuse me, but what is this thing for? 
  44.  
  45. If Gary will give his permission, I can post a copy of his letter.  It's
  46. in the archives somewhere on our PBBS here.
  47.  
  48. >Pedro Colla wrote a long article, pointing out what we have here: it is
  49. >a low bandwidth, anarchic, highly resilient network that will work,
  50. >eventually. Practical throughput, once there are more than two stations
  51. >involved, is a few tens or hundreds of baud. It is a thin network. Why
  52. >don't we give up on thinking of it as a ham Ethernet and start working
  53. >on more applications where this sort of information pipe will do some good?
  54.  
  55. I agree--I wasn't necessarily suggesting that we should create an alternate
  56. Internet.  The I-net examples I used were merely suggestions.  I do think,
  57. though, that a TCP/IP network wouldn't be bad.  Ie, e-mail could be handled
  58. by presently-existing SMTP applications.  We could use things like FTPMail
  59. for file/data transfer.  We could replace the existing haphazard system
  60. of bulletins with something using existing Usenet protocols, mail routing
  61. would be expedited.
  62.     It would also be easier to support things such as (I think)
  63. Gary Coffman suggested--ie, a simple FORTH-like language to carry out
  64. remote tasks.  I envision something like:
  65.  
  66.     : MAIN
  67.           "STTNG" dbselect         ( selects the database to be searched )
  68.       "worf" "riker" "troi" and and ( selects keywords to search for )
  69.           "picard" "riker" or not and   ( selects keywords to exclude )
  70.           SEARCH            ( executes the database search )
  71.     ;
  72.  
  73. which could then be compiled into a tokenized string that would be uploaded
  74. to the interpreter and executed.  If it worked, it'd self-delete and mail
  75. the results back to the originator, else it would be passed onto the next
  76. computer in the chain.
  77.     I've actually sort of spec'ed out something along these lines.  It
  78. wouldn't necessarily have to support recursion in the initial stages, and
  79. could be written with a relatively simple YACC grammar, methinks.  I think
  80. that the TinyMUCK code which supports the MUF programming language would be
  81. a good example of how something like this could work.
  82.  
  83. Ack.  I guess I've gotten off my original track.  But anyway.  This is,
  84. BTW, something which could be adapted to the Internet with fantastic
  85. results.  Imagine being able to mail such a search program off to an
  86. archie server, or a network of WAIS servers.
  87.  
  88. Food for thought.
  89.  
  90. 73 - doug
  91.  
  92. >73
  93. >David WA6NMF
  94.  
  95.  
  96. >-- 
  97. >David Josephson / Josephson Engineering / San Jose CA / david@josephson.com
  98. -- 
  99.          Doug Renze, N0YVW * drenze@isca.uiowa.edu * N0YVW @ W0IUQ.ia.usa.na
  100.                          DRenze@aol.com ** drenze@chop.isca.uiowa.edu
  101.  
  102. ------------------------------
  103.  
  104. Date: Sun, 5 Jun 1994 11:44:09 GMT
  105. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!pipex!uknet!cix.compulink.co.uk!packman@network.ucsd.edu
  106. Subject: An open note to Gary Coffman, KE4ZV
  107. To: ham-digital@ucsd.edu
  108.  
  109. > Hmmm...must ask my local Satgate operator about getting (another) > look
  110. > at the programs.  Sounds like it could be an interesting
  111. > experiment...even more interesting if the source code was available.
  112.  
  113. Just asked him and he says that whilst PB/PG (the user progs) are readily 
  114. available, he's never seen a Pacsat simulator program around. He reckoned 
  115. it might not be available due to 'commercial' interests in the satellite 
  116. program :(
  117.  
  118. Chris - G6FCI Packet   : G6FCI @ GB7FCI.#16.GBR.EU
  119. Internet : packman@cix.compulink.co.uk
  120.  
  121. ------------------------------
  122.  
  123. Date: 6 Jun 1994 04:58:02 GMT
  124. From: nothing.ucsd.edu!brian@network.ucsd.edu
  125. Subject: An open note to Gary Coffman, KE4ZV
  126. To: ham-digital@ucsd.edu
  127.  
  128. packman@cix.compulink.co.uk ("Chris Mcmahon") writes:
  129. >For Mr Joe User who is a black box operator that buys a TNC off the shelf
  130.  
  131. I do not sympathise with people who refuse to learn the state of the
  132. art.  They have chosen not to keep up; if they therefore can't do some
  133. of the more advanced things, that is the result of THEIR DECISION.
  134.  
  135. A falsely-perceived need for backwards-compatability has held back more
  136. progress than all the world's Luddites combined.
  137.     - Brian
  138.  
  139. ------------------------------
  140.  
  141. Date: 6 Jun 1994 04:54:26 GMT
  142. From: nothing.ucsd.edu!brian@network.ucsd.edu
  143. Subject: An open note to Gary Coffman, KE4ZV
  144. To: ham-digital@ucsd.edu
  145.  
  146. WB6YMH and I proposed the news broadcast scheme some years ago; it's
  147. been tossed around a number of times since, but no one has gotten around
  148. to writing the actual client (there is a sender).  Certainly the various
  149. clients intended for use with the PACSATS could (and do) work, but a
  150. more purpose-built client would be better.
  151.  
  152. I envision that the news would be broadcast CONTINUOUSLY in round-robin
  153. fashion - no need for the transmitter to ever unkey.  New articles would
  154. be added and old ones expired from the list over time.
  155.  
  156. User stations would run a background process (a "TSR" in MS-DOG parlance)
  157. that would suck in the articles as they're broadcast (selectively or not
  158. as the user specified), squirrel them away on disk, and update an index.
  159. Since the user station never has to transmit - fills happen automatically
  160. from the repeated broadcasts and error-correction coding could help -
  161. there's no issue of unattended transmitter operation - it's receive only!
  162.  
  163. When the user stopped playing space blaster, gets back from the office,
  164. or whatever, he'd be able to fire up a news reader and read the articles
  165. that had appeared.  Read them FAST, off local disk, not over the air.
  166.  
  167. I know that the idea of a continuous bulletin transmission doesn't sit
  168. well with a lot of hams, but in the USA it's legal and it's clearly efficient.
  169.  
  170. Some day I or someone else will write the client and then it'll be time
  171. to clank on the sender.  You know, a single 10-watt transmitter on a
  172. single 2m frequency on one mountaintop here in SoCal could cover
  173. thousands of square miles and serve thousands of hams all at once.
  174.     - Brian
  175.  
  176. ------------------------------
  177.  
  178. Date: Sat, 4 Jun 1994 14:50:49 +0000
  179. From: ihnp4.ucsd.edu!agate!doc.ic.ac.uk!uknet!demon!djwhome.demon.co.uk!david@network.ucsd.edu
  180. Subject: An open note to Gary Coffman, KE4ZV
  181. To: ham-digital@ucsd.edu
  182.  
  183. In article <1994Jun2.105141.15184@cnsvax.uwec.edu> whitemp@hemp (Mike White) writes:
  184. >Actually, the solution, as I see it, is to modify the 8250slip.com (or
  185. >whatever they call it nowadays) so that it operates with KISS rather
  186. >than slip.  KA9Q does a fine job, true, but it is an application and not
  187.  
  188. It's not quite as simple as this.  Amateur packet is a broadcast medium and
  189. needs an address resolution protocol.  SLIP is a point to point protocol and
  190. doesn't use an address resolution protocol.  A lot of TCP/IP software 
  191. actually doesn't support SLIP class drivers, so there are SLIP drivers which
  192. spoof ARP to keep the stack happy.  Also packet drivers assume that the
  193. higher software provides MAC level header information.  To run with normal
  194. stacks, you have to run ARP within the packet driver and map ethernet or 
  195. token ring addresses into callsigns within the driver.  (I think you also 
  196. have to handle parts of the AX.25 protocol, if you are using KISS.)
  197.  
  198. I seem to remember that there is an AX.25 class for packet drivers, but that
  199. would only work with AX.25 aware stacks (will KA9Q work with such drivers?).
  200. All this processing is going to make a KISS packet driver big and non-trivial
  201. to write, but not impossible.  It may have been done, but I would have
  202. expected it to have been mentioned in this thread by now, if that were the
  203. case.
  204. -- 
  205. David Woolley, London, England                     david@djwhome.demon.co.uk
  206. Demon is an IP/SMTP/NNTP Provider.  *.demon hosts are independently managed.
  207.  
  208. ------------------------------
  209.  
  210. Date: Sun, 05 Jun 1994 19:50:00 PST
  211. From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!mala.bc.ca!epaus!ham!emd@network.ucsd.edu
  212. Subject: An open note to Gary Coffman, KE4ZV
  213. To: ham-digital@ucsd.edu
  214.  
  215. davidj@rahul.net (David Josephson) writes:
  216.  
  217. 
  218. >ARESPACK from WN6I tracks who/where/what during a disaster. APRS plots
  219. >locations of stations, DF headings, station status, etc on a map from
  220. >information transmitted on packet. And the DX cluster is a perfect 
  221. >example of how we can use this mode to make things nicer. 
  222. >
  223.  
  224. ARESPACK sounds like just the thing I could use here as ESS Comms 
  225. director. Where can I find it?
  226.  
  227. Tnx, Bob.
  228.  
  229. emd@ham.island.net (Robert Smits Ladysmith BC)
  230.  
  231. ------------------------------
  232.  
  233. Date: 5 Jun 1994 10:48:31 GMT
  234. From: ihnp4.ucsd.edu!swrinde!howland.reston.ans.net!EU.net!Austria.EU.net!newsfeed.ACO.net!nippur.irb.hr!thphys!sinisa@network.ucsd.edu
  235. Subject: Ethernet address Directory?
  236. To: ham-digital@ucsd.edu
  237.  
  238. In <BAT.94Jun3070029@gdstech.GRUMMAN.COM> bat@gdstech.GRUMMAN.COM (Pat Masterson) writes:
  239.  
  240. > Each vendor has a whole BLOCK of ethernet addresses. So, each card
  241. >they make can have a different address. These blocks are listed in
  242. >an RFC, but I don't remember which one. And, for new ones, or
  243. >those that don't seem to be listed, you can call the IEEE and ask
  244. >them. They might not tell you who the vendor is, but they can have
  245.  
  246.  
  247. Also look on FTP.LCS.MIT.Edu , file pub/map/EtherNet-codes
  248. (via anonftp, of course).
  249. Great!
  250.  
  251.  
  252. >a vendor rep call you back if you need to identify some wayward
  253. >ethernet address.
  254. >-- 
  255. >*-----------------------------------------------------------*
  256. >*     Pat Masterson   D12-25  | KE2LJ@KC2FD                 *
  257. >*     Grumman Data Systems    | 516-346-6316.               *
  258. >*     Bethpage, NY 11746      | bat@gdstech.grumman.com     *
  259.  
  260. Sinisa
  261. --
  262. -----------------------------------------------------------------------------
  263. !  Sinisa Novosel, Institut Rugjer Boskovic, dep. FIZIKA; Croatia,Zagreb    !
  264. !                     sinisa@thphys.irb.hr                                  !
  265. -----------------------------------------------------------------------------
  266.  
  267. ------------------------------
  268.  
  269. Date: Sun,  5 Jun 94 08:54:28 GMT
  270. From: ihnp4.ucsd.edu!usc!math.ohio-state.edu!caen!news.umass.edu!nic.umass.edu!usenet@network.ucsd.edu
  271. Subject: GRINOS AND ETHERNET
  272. To: ham-digital@ucsd.edu
  273.  
  274. In Article <"940602.14:00:42*.G=KRISTOFF.S=BONNE.OU=PIRESSYS.O=BELGACOM.PRMD=RTTIPC.ADMD=RTT.C=BE."@MHS>
  275. kbonne@nx.rtt.rtt.BE (Kristoff BONNE) writes:
  276. ..
  277. >I've put NOS on a PC at my qrl to do some tests on the LAN.
  278. ..
  279. >When I send/receive 'a lot' of data ('a lot' being some hundred bytes), the 
  280. >session hangs. (the rest of NOS still works OK?)
  281.  
  282. I don't have an answer, but  have seen the problem with a slightly different 
  283. configuration (386, and a different packet driver). It occurs when I connect 
  284. via ethernet to a VAX or a Sun, both of which are set up to service large
  285. numbers of users.  The VAX session usually hangs up before it gets through 
  286. the messages of the day. The Sun will crash when I do an ls -l command
  287. on a moderately big directory.
  288.  
  289. I inquired on other groups about this and was given a suggestion that the 
  290. telnet escape character default for NOS was the problem, but in fact it made
  291. no difference.
  292.  
  293. I suspect the problem may be that NOS does dynamic memory allocation and 
  294. just can't do it fast enough to handle a large amount of data coming in fast,
  295. i.e., at ethernet speeds. Try using the "mem stat" command after this happens.
  296. I think a solution might be to recompile a NOS with less stuff in it, to use
  297. less memory. But I've never tried this.
  298.  
  299. The problem is not inherent in the ethernet interface per se, I can connect
  300. NOS via ethernet to another NOS box, to a Minix box, or to a couple of Linux
  301. systems. But these systems don't output as much data as the VAX or Sun. 
  302.  
  303.         Albert S. Woodhull
  304.         Hampshire College, Amherst, MA, USA
  305.         awoodhull@hamp.hampshire.edu
  306.  
  307. ------------------------------
  308.  
  309. Date: 5 Jun 1994 20:50:34 GMT
  310. From: bloom-beacon.mit.edu!senator-bedfellow.mit.edu!mit.edu!maui@uunet.uu.net
  311. Subject: Internet <-> Packet gateway
  312. To: ham-digital@ucsd.edu
  313.  
  314. Hi there:
  315.  
  316. This question is coming from someone who is Internet experienced but has
  317. very little HAM experience.  I am looking for a gateway to communciate
  318. with someone who has an address on a Packet BBS in AZ.  I know gateways
  319. between the Internet and Packet exist.  Can someone tell me where one is
  320. and how to use it?  Please e-mail me the answer to this question since I
  321. don't really read this newsgroup.
  322.  
  323. - Thanks -
  324.             ___
  325.             (|)ark Uhrmacher
  326.               maui@mit.edu
  327.  
  328. ------------------------------
  329.  
  330. Date: 06 Jun 1994 01:35:17 GMT
  331. From: yale.edu!noc.near.net!chaos.dac.neu.edu!chaos.dac!wy1z@yale.arpa
  332. Subject: Internet <-> Packet gateway
  333. To: ham-digital@ucsd.edu
  334.  
  335. In article <MAUI.94Jun5165034@xv.mit.edu> maui@mit.edu (Mark A Uhrmacher) writes:
  336.  
  337.    Path: chaos.dac.neu.edu!grapevine.lcs.mit.edu!olivea!decwrl!ames!agate!howland.reston.ans.net!pipex!sunic!trane.uninett.no!eunet.no!nuug!EU.net!uunet!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!mit.edu!maui
  338.    From: maui@mit.edu (Mark A Uhrmacher)
  339.    Newsgroups: rec.radio.amateur.digital.misc
  340.    Date: 5 Jun 1994 20:50:34 GMT
  341.    Organization: Massachusetts Institute of Technology
  342.    Lines: 13
  343.    Distribution: world
  344.    NNTP-Posting-Host: xv.mit.edu
  345.  
  346.    Hi there:
  347.  
  348.    This question is coming from someone who is Internet experienced but has
  349.    very little HAM experience.  I am looking for a gateway to communciate
  350.    with someone who has an address on a Packet BBS in AZ.  I know gateways
  351.    between the Internet and Packet exist.  Can someone tell me where one is
  352.    and how to use it?  Please e-mail me the answer to this question since I
  353.    don't really read this newsgroup.
  354.  
  355.    - Thanks -
  356.                ___
  357.                (|)ark Uhrmacher
  358.                  maui@mit.edu
  359.  
  360.  
  361. Check out: oak.oakland.edu:/pub/hamradio/docs/packet-internet
  362.  
  363. There is gateway info there.
  364.  
  365. If you need any help, please let me know.
  366.  
  367. Scott
  368.  
  369. --
  370. ===============================================================================
  371. | Scott Ehrlich           Amateur Radio: wy1z      AMPRnet: wy1z@wa1phy.ampr.org |
  372. | Internet: wy1z@neu.edu   BITnet: wy1z@NUHUB    AX.25: wy1z@wa1phy.ma.usa.na |
  373. |-----------------------------------------------------------------------------|
  374. |       Maintainer of the Boston Amateur Radio Club hamradio FTP area on      |
  375. |            oak.oakland.edu - /pub/hamradio                |
  376. ===============================================================================
  377.  
  378. ------------------------------
  379.  
  380. Date: Sat, 4 Jun 1994 14:30:58 GMT
  381. From: ihnp4.ucsd.edu!usc!cs.utexas.edu!utnut!torn!uunet.ca!uunet.ca!geac!torsqnt!problem!vigard!mdf@network.ucsd.edu
  382. Subject: Motorola GPS engine purchase information
  383. To: ham-digital@ucsd.edu
  384.  
  385. alanb@sr.hp.com (Alan Bloom) writes:
  386. >Marc T. Kaufman (kaufman@Xenon.Stanford.EDU) wrote:
  387. >: ... the GPS measured position changes with time (dithers).
  388. >
  389. >What is the time constant of the GPS Selective Availability dithering?
  390. >Does it change on the order of hours, minutes, seconds or even faster?
  391.  
  392. minutes, i believe.  the marine DGPS systems being setup by the US and
  393. Canadian coast guards broadcast pseudo-range corrections, at 50 bits
  394. per second, on top of existing navigation beacons in the 300-500kHz area.
  395.  
  396. >AL N1AL
  397. -- 
  398. Matthew Francey                     mdf@vigard.mef.org            ve3rqx@io.org
  399. "live before you die"               GPS(NAD27): N43o34.210' W079o34.563' +0093m
  400.  
  401. ------------------------------
  402.  
  403. Date: Sun, 5 Jun 1994 11:50:58 +0000
  404. From: ihnp4.ucsd.edu!swrinde!pipex!demon!g8dzh.demon.co.uk!John@network.ucsd.edu
  405. Subject: NPFPMS update version 2.20A available
  406. To: ham-digital@ucsd.edu
  407.  
  408. Version 2.20a of the G8NPF Personal Message System  (NPFPMS) is now available
  409. as a self-exploding file 'NPF220A.EXE'.  NPFPMS is designed to be used with
  410. G8BPQ node software (version 4.05 or greater) on PC-AT class (286 and higher)
  411. machines.  New functions since the last Internet release 2.16d include:-
  412.  
  413. * Support for FBB Unproto broadcasts to maintain message lists. Messages read
  414.   from FBB BBS's by the AutoRead function can use compressed file format.
  415.  
  416. * Archive Message facility added.
  417.  
  418. * Virtual (ram) disk (or a different hard disk) support for temporary files.
  419.  
  420. * Extensions added to YAPP transfer protocol. 
  421.     Crash recovery. Resume an aborted file download.
  422.     YappC checksum mode. (as used by FBB)
  423.  
  424. Plus many other improvements. NPF220A.EXE and information file NPF220A.TXT can
  425. be ftp'ed from :
  426.  
  427.     ftp.demon.co.uk [158.152.1.69]      /pub/ham
  428.     ftp.funet.fi    [128.214.248.6]     /pub/ham/packet/misc
  429.  
  430. -- 
  431. John Ray     | Internet:  John@g8dzh.demon.co.uk
  432. Loughton     | CI$        100041,305
  433. Essex        | AMPRnet:   g8dzh@gb7ine.ampr.org  [44.131.182.1]   
  434. England      | AX25:      G8DZH@GB7HSN.#32.GBR.EU   
  435.  
  436. ------------------------------
  437.  
  438. Date: Mon, 6 Jun 1994 01:13:19 GMT
  439. From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!ub!freenet.buffalo.edu!aa450@network.ucsd.edu
  440. Subject: Vester SSTV board
  441. To: ham-digital@ucsd.edu
  442.  
  443. In a previous article, jeff.smith@n9csa.com (Jeff Smith) says:
  444.  
  445. >Hey guys,
  446. >Can anybody make a Vester SSTV board ( QST Jan. 1994) for me? I will pay
  447. >you $$. I am a new ham awaiting my ticket but I have no electrical
  448. >knowledge. Please help!!! Leave me a message.
  449. >Thanks and 73's, Jeff
  450. >
  451. FAR has that board for sale.  See their add for address.  It's < $5.
  452.  
  453. But... the circuit is so simple you can use a scrap of perfboard just
  454. as well.  I bumped into Ben Vester at Dayton and he pulled his out of
  455. a pocket to show me, and.... it was a 2" square of perfboard.
  456.  
  457. Good luck,  Kurt
  458. -- 
  459.  
  460. ------------------------------
  461.  
  462. Date: Mon, 6 Jun 94 09:09:08 GMT
  463. From: ihnp4.ucsd.edu!swrinde!pipex!uknet!uos-ee!ee.surrey.ac.uk!M.Willis@network.ucsd.edu
  464. To: ham-digital@ucsd.edu
  465.  
  466. References <1994Jun3.150706.7300@ke4zv.atl.ga.us>, <CqvMru.A3D@cix.compulink.co.uk>, <2suacq$fvt@network.ucsd.edu>π
  467. Subject : Re: An open note to Gary Coffman, KE4ZV
  468.  
  469. In article <2suacq$fvt@network.ucsd.edu>, brian@nothing.ucsd.edu (Brian Kantor) writes:
  470. |> packman@cix.compulink.co.uk ("Chris Mcmahon") writes:
  471. |> >For Mr Joe User who is a black box operator that buys a TNC off the shelf
  472. |> 
  473. |> I do not sympathise with people who refuse to learn the state of the
  474. |> art.  They have chosen not to keep up; if they therefore can't do some
  475. |> of the more advanced things, that is the result of THEIR DECISION.
  476. |> 
  477. |> A falsely-perceived need for backwards-compatability has held back more
  478. |> progress than all the world's Luddites combined.
  479. |>     - Brian
  480.  
  481. And a falsely-perceived need for change has held back progress even more. You can't
  482. just write off a worlds worth of equipment because it is now possible to go twice
  483. as quickly.
  484.  
  485. Regarding your lack of sympathy, are you unsympathetic to the unwilling or the
  486. incapable?
  487.  
  488. How many times does it need to be proved that the average person does not
  489. have the intellect to keep up with the state of the art? Perhaps we should take
  490. away the licences of all those black boxers who can not pass a new, suitably
  491. difficult, technical exam? 
  492.  
  493. The reason people refuse to learn the state of the art is that the majority of
  494. those who are at that level are either incapable of teaching others or make things
  495. so difficult to understand that no-one else has a chance. For example, TCP/IP.
  496. There are a lot of developers out there who have written some very clever software.
  497. In the main the manuals are terrible. They are concise, exact and tell the beginner
  498. nothing. Acronyms are used all over the place, yet no list of acronyms is provided
  499. so you need to remember each one. Software that is not easy to use is bad software.
  500. If you require a large amount of technical insight to use an item, then it is badly 
  501. designed.
  502.  
  503. When it is so hard to get started, no wonder those with less ability give up. I
  504. agree that we need to get rid of the CB mentality type of black box operator who
  505. knows nothing and is able, but not prepared, to learn.
  506.  
  507. Mike
  508.  
  509. ------------------------------
  510.  
  511. Date: Mon, 6 Jun 1994 00:58:09 GMT
  512. From: news.Hawaii.Edu!uhunix3.uhcc.Hawaii.Edu!jherman@ames.arpa
  513. To: ham-digital@ucsd.edu
  514.  
  515. References <2skvhe$qov@Times.Stanford.EDU>, <CqsAx8.155@srgenprp.sr.hp.com>, <1994Jun4.143058.18107@vigard.mef.org>
  516. Subject : Re: Motorola GPS engine purchase information
  517.  
  518. In article <1994Jun4.143058.18107@vigard.mef.org> mdf@vigard.mef.org (Matthew Francey) writes:
  519. >
  520. >minutes, i believe.  the marine DGPS systems being setup by the US and
  521. >Canadian coast guards broadcast pseudo-range corrections, at 50 bits
  522. >per second, on top of existing navigation beacons in the 300-500kHz area.
  523.  
  524. That wouldn't be very helpful to the ham community - those beacons
  525. you speak of (285-325 kc is the maritime beacon band; the aeronautical
  526. beacons operate from 200 to 415 kc) only have a range from 5 to 50 miles.
  527.  
  528. Jeff NH6IL
  529.  
  530. ------------------------------
  531.  
  532. End of Ham-Digital Digest V94 #182
  533. ******************************
  534.